Smart IC card system and smart IC card with transaction management program stored therein

ABSTRACT

Smart IC cards are ones which themselves control performance of their transactions, in order to avoid an IC card reader having to be specialized in particular transaction types. A smart IC card system includes at least one IC card reader (1) and an IC card (4) which stores a transaction management program in a memory thereof. The reader (1) controls exchange cycles by alternately and repetitively sending to the IC card (4), on the one hand a request for provision of a packet of instructions and data, this being referred to as the &#34;card message&#34; and, on the other hand, a report declaration associated with a report message regarding the execution by the reader (1) of instructions previously received in card messages. The IC card (4) controls processing cycles synchronous with exchange cycles by virtue of a device for executing a transaction management program, developing instructions and data of the card messages at a rate of card-message provision requests and report declarations sent by the reader (1).

BACKGROUND OF THE INVENTION

1. Field of the Invention

The term IC card is used to denote cards, generally with the size of acredit card, but alternatively tokens, which are provided with anelectronic microcircuit based on memories and a microcontroller designedto make it possible to perform a transaction, for example a financial ormedical transaction.

The present invention relates to a system which is formed by an IC cardand an IC card reader which makes it possible to execute the transactionfor which the IC card is intended.

2. Discussion of the Background

Known systems having an IC card and reader include, on the one hand, ICcards which are provided with memories and possibly a microcontrollerand are used merely as a data medium supplemented by security means and,on the other hand, IC card readers which are intelligent enough tocontrol the performance of the transaction in question.

IC card readers are equipped with a system which provides a link to anIC card, either by means of a multipin electrical connector, or by meansof a capacitive or inductive antenna. They may be self-contained andwork on their own, or transparent and used to access a computer system.When they are self-contained, they have communication elements which aresufficient to allow an individual to monitor the steps of a transaction:keyboard and display which, like the link to the IC card, are managed bythe reader's own microcontroller which has an application programspecific to the transaction in question. When they are transparent, theybehave as a simple input/output port, dedicated to an IC card, for acomputer system programmed especially for the transaction in question.In both cases, they transmit instructions to the IC card, which are setin a form which accords with a specific exchange protocol, often the onedefined in standard ISO 7816-3, and the IC card merely executes theseinstructions and gives the report.

The intelligence of the transaction lies either in the reader or in thecomputer system associated with the reader. The drawback of this is theneed for specialization of the reader, or the associated computersystem, according to the type of transaction. Thus, if the type oftransaction needs to be changed, it is not enough to change theprogramming of the IC card. It is also necessary to change theprogramming of the reader, if it is self-contained, or the programmingof the associated computer system, if the reader is a transparent one.This constitutes an obstacle to the development of IC card applications.

To overcome this drawback, it has been proposed to shift theintelligence, that is to say the management of the transaction, to theIC card itself, which then stores the transaction management program inits memory and executes it.

The reader then becomes an external component whose main function is toprovide the resources needed for carrying out the transaction and, inparticular, to provide the IC card with interfaces such as a keyboard,display, asynchronous link and means for connecting to another IC cardor to a computer system.

The problem then arises of supplying the reader with certaininstructions to be carried out in relation to the transaction managementprogram which is stored in a memory in the IC card and is run by it.

In order to solve this problem, it is known, for example from EuropeanPatent Application EP-A-0,490,455, to define a communication protocolbetween an IC card and an IC card reader using a small number ofspecific commands for certain actions asked of the reader by an IC card,and requests and responses on the part of the reader which arecompatible with these commands, having fairly general characteristics inorder to suit various types of IC cards and readers. However, thissolution has the drawback of limiting the possibilities and nature ofthe exchange between an IC card and its reader to a fairly narrowframework due to the specificity of the commands, requests andresponses. It also has the drawback of no longer making it possible toadhere to the existing standards regarding the management ofcommunications between an IC card and an IC card reader, andconsequently of being incompatible with the previous generation of ICcards.

SUMMARY OF THE INVENTION

The object of the present invention is to provide a communicationprotocol between a smart IC card and an IC reader which places the leastpossible limitation on the exchanges between an IC card and its reader,in order to avoid specialization of the IC card reader in a particulartype of IC card, this protocol being easy to make compatible withexisting standards regarding the management of communications between anIC card and its reader.

It relates to a system for smart IC cards, including at least one ICcard reader provided with IC card supply means which are activated bythe connection of an IC card, and an IC card which stores a transactionmanagement program in its memory. This system is noteworthy in that theIC card reader includes:

means which alternately and repetitively generate, for the purpose ofbeing sent to a connected IC card, on the one hand a request forprovision of a packet of instructions and data developed in the said ICcard, this being referred to as the "card message" and, on the otherhand, a report declaration associated with a report message regardingthe execution by the reader of instructions previously received in cardmessages from the said IC card, the report declaration and the reportmessage being referred to as the "reader report",

means for receiving and processing the card message delivered by thesaid IC card subsequent to a request to provide a card message, and

means for developing and transmitting reader report messages subsequentto execution of instructions received from the said IC card in cardmessages, and in that the said IC card includes:

initialization means which are activated when the said IC card ispowered up and cause the said reader to be provided with a first cardmessage,

means for recognizing a card-message provision request originating fromthe said reader and for transmitting a card message to the said readerin response to such a card-message provision request,

means for recognizing a report declaration and for processing theassociated report message coming from the said reader, and

means for executing the said transaction management program, developingthe instructions and data of the card messages at the rate of thecard-message provision requests and the report declarations sent by thesaid reader.

Advantageously, a card-message provision request originating from the ICcard reader consists of a command, of the "get response" type, normallyused in standards ISO 7816/prEN726 to send prepared data to the reader,while a report declaration originating from the reader consists of acommand, of the "envelope" or "execute" type, normally used in standardsISO 7816/prEN726 to send data or have a program executed in an IC card.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete appreciation of the invention and many of the attendantadvantages thereof will be readily obtained as the same becomes betterunderstood by reference to the following detailed description whenconsidered in connection with the accompanying drawings, wherein:

FIG. 1 is a block diagram of the smart IC card system according to thepresent invention.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

Other characteristics and advantages of the invention will emerge fromthe following description of an embodiment of the invention, which isgiven by way of example. This description will be given with referenceto the drawing, in which FIG. 1 schematically illustrates the variouslogic levels of the programs of a smart IC card and of the associatedreader of a system according to the invention.

FIG. 1 shows the broad partitions of the management programs of themicrocontrollers of an IC card reader 1 equipped with a display screen 2and a keyboard 3, and of a smart IC card 4.

For the reader 1, the lowest level of its operating program is a baseoperating system 10, in executable code, which is designed for the typeof microcontroller and manages its memory. This base operating system 10is associated with a command interpreter 11 which recognizes the varioushigh-level language instructions which a card message may contain. Ontop of this combination there is an intermediate level consisting of acontrol program 12 which oversees the various elements of the reader,and an outer level consisting of various peripheral management programs,including a program 13 for managing communication with an IC cardaccording to standard ISO 7816-3, a program 14 for display screenmanagement, a program 15 for keyboard management and a program 16 forasynchronous serial port management for a possible link to a remotecomputer system. The control program 12 directs the commands originatingfrom the card messages to the command interpreter 11, constructs thereport messages intended for the IC card, develops the succession ofcard-message provision requests and report declarations intended for theIC card, and interfaces with the base operating system and the variousperipheral management programs.

For the smart IC card 4, the lowest level of its operating program isagain a base operating system 40, in executable code, which is designedfor the type of microcontroller and manages its memory, with the usualsecurity systems for an IC card, and an external communication protocol41. This base operating system 40 is associated with a commandinterpreter 42 which is resident in ROM and recognizes the high-levellanguage commands. On top of the combination of the base operatingsystem 40 and command interpreter 41 there is an outer level consistingof a high-level language program 43 for managing the transaction forwhich the IC card is intended, this program being stored in EEPROMmemory.

The reader 1 communicates with the smart IC card 4 by means of analternate two-way link, using a succession of cycles of two successivecommands from standards ISO 7816/prEN726, namely the "get response"command and the "envelope" or "execute" command.

The "get response" command consists of sending the binary messagecomprising five successive one-byte fields:

a first field, denoted "CLA", containing a byte identifying the class ofthe instruction, for example instructions reserved for financialapplications,

a second field, denoted "INS", containing the byte C0 in hexadecimal,identifying the "get response" command type,

a third reserved field, denoted "P1", containing the byte 00 inhexadecimal,

a fourth reserved field, denoted "P2", containing the byte 00 inhexadecimal,

a fifth field, denoted "Le field", containing a byte whose value ncorresponds to the number of bytes expected in response from the ICcard.

This "get response" command prompts a so-called "Data field" responsefrom the IC card, containing n data bytes, n being the number declaredin its "Le field", and two bytes "SW1, SW2", giving a card report.

The "execute" command consists in sending the binary message consistingof five successive one-byte fields and a final multi-byte data field:

a first field, denoted "CLA", containing a byte identifying the class ofthe instruction, for example instructions reserved for financialapplications,

a second field, denoted "INS", containing the byte AE in hexadecimal,identifying the "execute" command type,

a third reserved field, denoted "P1", containing the byte 00 inhexadecimal,

a fourth reserved field, denoted "P2", containing the byte 00 inhexadecimal,

a fifth field, denoted "Lc field", containing a byte whose value ncorresponds to the number of bytes in the message accompanying the"execute" command, and

a sixth, final field, denoted "Data field", containing the n data bytesannounced in the fifth field "Lc field". This "execute" command promptsa response from the IC card with two bytes "SW1, SW2", giving a cardreport.

The "envelope" command has the same structure as the "execute" commandand differs from it by the value of the byte of its second field "INS"identifying the command which has the value C2 in hexadecimal.

In these three messages, the respective fields "Le field" and "Lc field"declare the length of the expected card message, or the length of thereport message from the reader, which are used to carry the instructionsto be executed and associated data coming from the IC card and, inreturn, the reports of the actions executed by the reader, as well asresulting data.

When the IC card 4 is inserted into the reader 1, the IC card isdetected and powered up by the reader 1, which sends it an answer toreset according to standard ISO 7816-3. This results in a process ofinitializing the microcontroller of the IC card 4, which ends with ananswer to reset being sent to the reader 1 from the IC card 4, and witha start-up of the transaction management program of the IC card 4 for afirst processing cycle which, in this card, leads to the preparation ofthe first card message which it will be possible to communicate to thereader 1 as soon as the latter has asked for it by means of a messageprovision request in the form of a "get response" command.

On receipt of the acceptance response to the answer to reset, the reader1 embarks upon a first cycle of data exchange with the IC card 4.

During this first exchange cycle, the reader 1 sends the IC card 4 amessage provision request in the form of a "get response" command, inorder to request the sending of the card message prepared by the IC card4 after its initialization.

On receipt of such a request through the "get response" command, the ICcard 4 sends the prepared card message to the reader 1.

The reader 1 receives the card message, identifies the data which itcontains, interprets the message, executes the requested commands andresponds to the IC card 4 by a report declaration in the form of an"envelope" or "execute" command, with a report message telling the ICcard 4 how it has performed what was asked of it, and the result of thisprocessing. This completes the first exchange cycle.

On receipt of the "envelope" or "execute" command for the first exchangecycle coming from the reader 1, the IC card 4 continues to run itstransaction management program in a second processing cycle, duringwhich it firstly checks for correct execution of the card message whichit has just sent, using the report message, then prepares another cardmessage.

The reader 1 then embarks upon a second exchange cycle by sending asecond "get response" command to the IC card 4 in order to read the newcard message. After processing the data of this new card message, thereader 1 reports its execution to the IC card 4, by means of a reportmessage incorporated with a second "envelope" or "execute" command,which concludes the second exchange cycle.

On receipt of this second "envelope" or "execute" command coming fromthe reader 1, the IC card 4 then, still under the control of itstransaction management program, embarks upon a third processing cycle,during which it checks for correct execution of the card message whichit has just sent, by means of the report message received from thereader 1, then prepares another card message.

The reader 1 then embarks upon a third exchange cycle by sending a third"get response" command to the IC card 4 in order to receive this cardmessage.

The processing cycles, instigated by the IC card 4, and exchange cycles,instigated by the reader 1, thus succeed one another according to thetransaction management program stored in the IC card 4.

According to standard ISO 7816-3, the reader 1 is in control of theexchanges in electrical terms, but the transaction runs at theinstigation of the IC card 4, which is a smart card.

In the case when the system includes several IC cards, only one card ata time runs the transaction. The IC card running the transaction isreferred to as "active". The others are referred to as "passive". Thefirst IC card capable of answering a "get response" instruction from thereader is the one declared active.

As mentioned above, the "get response" command is used by the reader toask the IC card which has been declared "active" for the types ofoperation which it is to perform during a transaction.

There are quite a wide variety of types of operation which an active ICcard can ask for from the reader. Examples of these include:

a request to configure the reader, to which the reader returns a reportsummarizing its main characteristics,

a stop/restart of the reader, to which the reader returns a reportgiving its operating state,

installing a program into the reader, using call parameters contained incard messages, for example: name of the program, length and content ofthe program. In reply to this installation, the reader returns a reporton its status and the data of the installation carried out.

executing an installed program using call parameters contained in cardmessages, for example: name of the program, length of the data, calldata of the program. In reply to this execution, the reader returns areport on its status and the length of the data in return.

a request to open/close an asynchronous link, by means of callparameters contained in card messages, for example: port number,correspondent identifier, direction. In reply to this request, thereader returns a report on the status and the number of the port inquestion.

a request to display an operator message, by means of call parameterscontained in card messages, for example: type of message (permanent,outstanding, etc.), type of display (steady, flashing, etc.), number ofelements in the message, co-ordinates of each element in the message,length of the label, label. In reply to this request, the reader returnsa status report.

a request for selection from a menu, by means of call parameterscontained in card messages, for example: type of menu, number of linesin the menu, name of the line, co-ordinates of each of the selections,label. In reply to this request, the reader returns a report indicatingthe number of the selected line.

a request to enter in a grid, by means of call parameters contained incard messages, for example: name of the grid, type of the grid (initial,concatenation, etc.), number of questions, co-ordinates of the label ofeach question, co-ordinate of each response, maximum number ofcharacters to be entered, type of field (entry obligatory, notdisplayed, not modifiable, etc.), length of the label of the question,label of the question, number of characters of the default value of theresponse, default value of the response (omitted if the length is zero).In reply to this request, the reader returns a report including either:

the name of the grid, the number of a question and a request forcomplementary action or an entered value,

an abort,

the name of the grid, a validation, the date and time,

writing to a file of the reader, by means of call parameters containedin card messages, for example: file name, address in the file, length ofthe data to be written and the actual data to be written. In reply tothis request, the reader returns a report giving the status and the filename.

a request for external authentication with, in return, a report givingproof of the validity of the reader,

exchange of ciphered/deciphered data, by means of call parameterscontained in card messages, for example: length of theciphered/deciphered data and the ciphered/deciphered data, with a reportin return from the reader giving the key number, the length of the dataand the data themselves,

a file signature request, by means of call parameters contained in cardmessages, for example: the name of the file, with a report in returnfrom the reader giving the requested signature,

a request to execute a command for a passive IC card, by means of callparameters contained in card messages, which consist of commands in thepassive card format according to standard ISO 7816-4, with a report inreturn giving a status, the length of the data in return and the data inreturn,

a request to execute a "standard" command of the reader, by means ofcall parameters contained in card messages, with a reader report.

The term "standard" reader command means any command which the operatingsystem of the reader can execute. "Standard" commands comprise, inparticular:

a request to create/delete a directory in the memory of the reader,

a request to select a directory from the memory of the reader,

a request to read the content of a directory of the reader,

a request to create/delete files in the current directory of the reader,

a request to copy/back-up/restore files of the reader to a communicationport (IC card or asynchronous),

a request to run an executable file,

the installation of a program in the reader application from a readerfile,

a print request if the reader is equipped with or connected to aprinter,

a date and time request,

etc.

Furthermore, the reader may itself signal certain external events:

request for connection of an asynchronous link (no. of the port,identifier of the requester),

insertion of a card (no. of the inserted card, ATR),

withdrawal of a card (no. of the extracted card),

keyboard inactivity,

etc.

Obviously, numerous modifications and variations of the presentinvention are possible in light of the above teachings. It is thereforeto be understood that within the scope of the appended claims, theinvention may be practiced otherwise than as specifically describedherein.

What is claimed as new and desired to be secured by Letters Patent ofthe United States is:
 1. A system for smart IC cards, including:at leastone IC card reader provided with IC card supply means which areactivated by connection of an IC card thereto; and an IC card whichstores a transaction management program in a memory provided therein;wherein said IC card reader, includes,means which alternately andrepetitively generate, for purpose of being sent to a connected IC card,a request for a provision of a packet of instructions and data developedin said IC card, said request referred to as a card message, and areport declaration associated with a report message regarding executionby said IC card reader of instructions previously received in cardmessages from said IC card, said report declaration and report messagereferred to as a reader report, means for receiving and processing saidcard message delivered by said IC card subsequent to a request toprovide a card message, and means for developing and transmitting saidreader report subsequent to execution of instructions received from saidIC card in said card messages; said IC card, includes,initializationmeans which are activated when said IC card is powered up and whichcause said IC card reader to be provided with a first card message,means for recognizing a card-message provision request originating fromsaid IC card reader and for transmitting a card message to said IC cardreader in response to said card-message provision request, means forrecognizing a report declaration and for processing the associatedreport message coming from said IC card reader, and means for executingsaid transaction management program, developing instructions and data ofsaid card messages at a rate of card-message provision requests andreport declarations sent by said IC card reader.
 2. The system of claim1, wherein said means for executing said transaction management programdevelop instructions for:a request to display a message intended for anoperator, a request to select a menu, a request to enter a grid, arequest to display a grid or a field, a request to execute a command bysaid card message receiving and processing means of said IC card reader,a request to record a file, a request for external authentication, arequest for ciphering, a request for deciphering, a request for a filesignature, a request to install a program, and a request to execute apreviously installed program.
 3. The system of claim 1, wherein saidmeans for developing a report message of said IC card reader developreport messages regarding:a menu selection, a field entry, a response toa request to execute a command by said card-message receiving andprocessing means of said IC card reader, an insertion of said IC cardinto said IC card reader, a withdrawal of said IC card from said IC cardreader, inactivity of a keyboard, authentication of said IC card reader,an install report, and a request for an asynchronous link.
 4. The systemof claim 1, wherein said alternately and repetitively generate means ofsaid IC card reader develops said card-message provision request in aform of a digital sequence having a plurality of successive fields,including a command identification field and a field for declaring alength of an expected card message.
 5. The system of claim 1, whereinsaid alternately and repetitively generate means of said IC card readerdevelops a report declaration in a form of a digital sequence having aplurality of successive fields, including a command identification fieldand a field for declaring a length of the associated report message.